I think the problem here is that my timeout in the original test was too optimistic. It may take a full sync interval in the kubelet to pick up the change; bumping way up to avoid future timeouts.

guess there's no way to programatically make the sync happen sooner?

Is there a way to link this directly to the sync interval, so it floats against it?

Also, it should be ≤2*interval, right?

If this is an update that needs to be processed by a pod worker, we shouldn't go fine with timeouts. The kubelet needs to wake up and invoke the worker. You can probably engineer a timeout that matches pretty fine with when a pod worker is woken up. But if a worker is already doing work, or many workers are up and competing for cpu, there's very little you can do to guarantee it does work exactly on some edge of the kubelet sync.

Employ the same strategy as we do for pod readiness? (poll till 5m)

Polling for 5 min sounds legit -- does that mean this should move to [Slow]?

I think there are too many tests that poll for 5m in gce normal. I think we can catch if this just keeps crossing 5m via the test dashboard, I don't think any of the tests that currently poll for 5m actually do. If one of the generic timesout in e2e/util are applicable in this case, just use that and we'll bump all at the same time if we do?